RTnet, a new approach to in-home real-time multimedia communication

This abstract describes a new approach to token management for in-home digital networks, which we call RTnet. The proposed network offers a guaranteed quality-of-service, based on a distributed token mechanism to schedule communication streams. RTnet is based on the CSMA/CD Ethernet protocol [1]. In effect this means that RTnet can be built on any existing Ethernet specification and regular Ethernet hardware can be used without modification. CSMA/CD uses an exponential back-off mechanism to resolve collisions, which makes the network non-deterministic, and thus non-real-time. To make it deterministic, a token-based protocol is deployed to avoid collisions, just like Rether [2], developed at SUNY Stony Brook. Rether distributes its token among the nodes in a simple, static Round-Robin manner. RTnet, however, uses a more sophisticated algorithm, where the token is allocated to nodes according to their bandwidth demands. A preemptive earliest deadline first (EDF) scheduler is used to determine the route a token follows in the network. This type of scheduler has the advantage over other schedulers that it can achieve a 100% utilization. However, in case of overload its performance will degrade dramatically. Whenever a node has the token (the active node) it may use the network for some time: the token holding time (THT). The THT is determined by the scheduler and is likely to be different for each node. Typically the node will send one frame of a periodic multimedia stream. Note that our network works with constant-bitrate streams, but variable-bit-rate streams can be mapped using several techniques [3]. The EDF scheduler is distributed over the nodes and the token is the place where the schedule is kept; nodes will keep backups of the schedule though. If a node has the token and it wants to add or remove a stream, it calculates a new schedule and acts upon it. Before a new stream may be added the node does an EDF feasibility test to determine if the newly added real-time stream will meet its deadlines without making other streams miss theirs. The EDF feasibility test is simple [4]: the total of bandwidth utilizations by all streams may not exceed 100%. However, only 80% of network bandwidth is dedicated to real-time (multimedia) communications, the rest is used for non-real-time purposes. Actually, the maximum bandwidth is slightly less because of the token transmission and Ethernet packet overhead. When the scheduler at the active node decides that another node must become active it stores the global schedule information in the token and sends the whole package to the new node. This is a critical action and it should never occur that the token becomes lost, or worse, duplicated. When a token is lost the schedule is lost too and the network stalls. Duplicated tokens mean that more than one node will make schedules and collisions will occur, causing deadline misses and non-deterministic behaviour. To prevent this the concept of a monitor is introduced. When the active node relinquishes the token, this node becomes the monitor for the new active node. Monitoring is a three step process: (1) the monitor sends the token to the new active node. If the token is garbled the active node will request a new token. This happens only once. If a second token is garbled too, the active node stays inactive, while the monitor times out and recovers the token. (2) The active node is now in the ‘transmission state’ for the duration of the THT. While the active node transmits, the monitor waits for a reply from the active node. It sets a timer for the duration of the THT. (3) At the end of the THT the active node must send a reply to the monitor signalling that it is still alive and sends the token to a new active node. The old monitor now ends its activity, the old active node becomes monitor, and the new active node begins transmitting. Then the process starts all over. Many things can go wrong. Detectable token loss situations are: token does not arrive at new active node, reply from active node is lost, active node dies before sending a reply, and the monitor dies. Undetectable token loss occurs when: the active node dies after sending a reply, and the monitor and active node die simultaneously. Token duplication is difficult to detect, but there are some hints the network will give: a token arrives at a node that already holds a token, and streams miss their deadlines because nodes cannot resolve bandwidth requirements. If a node detects this, it will delete the token. The network will probably end up without a token and initiate a reset. To validate correctness, robustness and usability of RTnet a simulation of the network protocols is made, and a prototype is realized for demonstration and calibration of the simulation. The prototype is based on the Linux operating system and Ethernet hardware. From the simulation we found the following general characteristics: (1) the total bandwidth utilization is very close to the set 80%, (2) the smaller the stream periods, the higher the overhead, and (3) the higher the offered load, the higher the overhead. The simulation was carried out using a network of 5 nodes, where we tested with combinations of 1, 3, 6, 10, and 25 streams, comprising offered total loads of 10%, 20%, 50%, 70%, and 80%, thus creating a total of 125 tests. Some figures calculated from the simulation are: average overhead per stream related to total bandwidth: 0.54%; average worst-case overhead per stream related to total bandwidth: 0.78%; average overhead per stream related to effective stream utilization: 1.33%; and average worst-case overhead per stream related to effective stream utilization: 1.95%. The feasibility test always computes the worst-case overhead and uses that to check if the total utilization does not exceed the maximum real-time utilization. This is checked by the simulation, where worst-case overhead is higher than real overhead in every case.